The logic for determining which endpoints to display could be clearer. The condition endpointMapping.IsExternal || scheme is "http" or "https" is confusing because:

1. externalEndpointMappings on line 371 already filters to external endpoints
2. When FirstOrDefault returns no match (line 410), endpointMapping will be the default struct value where IsExternal = false
3. The fallback to checking scheme is "http" or "https" suggests the intent is to show all http/https ports even without explicit mapping

Consider adding a comment to clarify this logic, or restructuring to make the intent clearer:

// Show endpoint if: it matches an external endpoint mapping, OR it's an http/https port (published ports are external by default)
var hasExplicitMapping = endpointMapping.Resource is not null;
if (hasExplicitMapping || scheme is "http" or "https")
{
    var endpoint = $"{scheme}://localhost:{publisher.PublishedPort}";
    endpoints.Add(endpoint);
}

Missing blank line before the XML documentation comment. According to the codebase formatting conventions, there should be a blank line between the closing brace of the constructor and the XML documentation comment for the next member.

The PrintEndpointsAsync method is missing XML documentation. According to the Aspire XML documentation guidelines, internal methods should have brief <summary> tags explaining what they do. Consider adding:

/// <summary>
/// Prints the endpoints for the Docker Compose service after deployment.
/// </summary>

The new endpoint printing functionality introduced in the PrintEndpointsAsync method and the pipeline step configuration lacks test coverage. Consider adding tests to verify:

• Endpoint discovery and display when containers are running
• Behavior when no external endpoints are configured
• Handling of multiple endpoints with different schemes
• Error handling when Docker Compose commands fail

The test file tests/Aspire.Hosting.Docker.Tests/DockerComposePublisherTests.cs has comprehensive test coverage for other Docker Compose functionality and would be an appropriate location for these tests.

Remove this declaration and check for dockerComposeFilePath since we do it in DockerComposeEnvironmentResource.GetDockerComposeArguments now.

@copilot add a comment that shows an example of the expected format being parsed here from docker compose.

@copilot add a comment that shows an example of the expected format being parsed here from docker compose.

Doesn't this need to handle potential slow startup of services? What guaranteees that docker compose ps --format json will have the information by the time you call it?